Mechanism for transparently interfacing with a third party version control system

ABSTRACT

Approaches for transparently interfacing with a third party version control system (VCS) are provided. In one approach, an enterprise application integration (EAI) system comprises an integrated development environment (IDE) client, a repository, an API, and an API implementation. The IDE client enables a user to develop one or more functional components that can be used or executed to derive one or more enterprise application functionalities. The repository interacts with the IDE client to save and access the one or more functional components. The API is invoked by the repository to interact with any VCS. The API implementation enables the repository, by way of invoking the API, to interact with a VCS, which is an external VCS that is not provided as part of the EAI system.

BACKGROUND

Early software programs in areas such as inventory control, humanresources, sales automation, and database management were designed torun independently, with no interaction between the programs. Theprograms were custom built in the technology of the day for a specificneed being addressed and were often proprietary systems. As enterprisesgrew and recognized the need for their information and applications tohave the ability to be transferred across and shared between systems,companies began investing in enterprise application integration (EAI)systems in order to streamline processes and keep all the elements ofthe enterprise interconnected.

Some EAI systems include an integrated development environment (IDE;also known as “integrated design environment” and “integrated debuggingenvironment”). An IDE is a type of computer software that assistscomputer programmers in developing integrated software applications.IDEs typically consist of a source code editor, a compiler and/orinterpreter, build-automation tools, and (usually) a debugger. Sometimesa version control system (VCS) and various tools to simplify theconstruction of a GUI are integrated as well. Although somemultiple-language IDEs are in use, such as the Eclipse IDE, NetBeans,and Microsoft Visual Studio, an IDE is typically devoted to a specificprogramming language, as in the Visual Basic IDE.

Today, many EAI systems contain their own VCS. However, many enterprisesthat purchase EAI systems prefer to continue to use their existing thirdparty VCS rather than the embedded VCS of their respective EAI system.Common third party VCSs include Concurrent Versions System (CVS), SourceCode Control System (SCCS), and Clear Case. Such enterprises typicallyconfigure an IDE client to interact directly with the third party VCS.In order to use a third party VCS, an integration project is savedlocally as components (e.g., files) and the components are then checkedinto the third party VCS. A plug-in (i.e., an API) is used to allow theIDE client to interact with the third party VCS.

FIG. 1 is a block diagram illustrating this approach for enabling an IDEclient 102 to interact with a third party VCS. IDE client 102 interactswith a VCS through a version control API 104. The API 104 is implementedby an API implementation 106.

The system of FIG. 1 may operate as follows. A source file for a codingproject is created and stored locally on IDE client 102. A user (e.g.,through a GUI of IDE 102) initiates a check-in operation, whereby IDE102 invokes the VCS API 104, which causes the API implementation 106 tobe executed. In turn, the API implementation 106 invokes the check-infunction of the VCS 110, which causes the source file to be stored indata storage 112.

A disadvantage of the above approach is the significant risk of losingwork if a user does not take the steps necessary to check in modifiedfiles to a VCS. For example, if a user forgets to check in modifiedfiles, then all the changes may be lost when the user logs out of thesystem. Therefore, there is a need to provide a better mechanism forenabling a third party VCS to be used in an EAI system.

The approaches described in this section could be pursued, but are notnecessarily approaches that have been previously conceived or pursued.Therefore, unless otherwise indicated herein, the approaches describedin this section are not prior art to the claims in this application andare not admitted to be prior art by inclusion in this section.

SUMMARY

An approach for transparently interfacing with a third party versioncontrol system (VCS) is provided herein. According to an embodiment, anenterprise application integration (EAI) system comprises an integrateddevelopment environment (IDE) client, a repository, an API, and an APIimplementation. The IDE client enables a user to develop functionalcomponents that can be used or executed to derive one or more enterpriseapplication functionalities. The repository interacts with the IDEclient to save and access the functional components. The API is invokedby the repository to interact with any VCS. The API implementationenables the repository, by way of invoking the API, to interact with aVCS, which is an external VCS that is not provided as part of the EAIsystem. Thus, the IDE client need not be concerned with aspects of theVCS because the repository takes care of them.

In one embodiment, multiple API implementations may be provided. TheseAPI implementations enable the same API to be used to interact withdifferent VCSs.

BRIEF DESCRIPTION OF THE DRAWINGS

The systems and methods described herein are illustrated by way ofexample, and not by way of limitation, in the figures of theaccompanying drawings. Similar reference numbers are used throughout thedrawings to reference similar elements and features.

FIG. 1 is a block diagram illustrating one approach for providing athird party VCS to an IDE client.

FIG. 2 is a block diagram illustrating a repository that interacts witha third party VCS, in accordance with an embodiment of the presentinvention.

FIG. 3 is a block diagram that illustrates a computer system upon whichan embodiment in accordance with the present invention may beimplemented.

DETAILED DESCRIPTION OF THE EMBODIMENT(S)

The systems and methods described herein relate to transparentlyinterfacing with a third party version control system. For purposes ofexplanation, numerous specific details are set forth in order to providea thorough understanding of the various systems and methods. It will beapparent, however, that the systems and methods described herein may beimplemented without these specific details. The specification anddrawings are, accordingly, to be regarded in an illustrative rather thana restrictive sense.

System Overview

FIG. 2 is a block diagram illustrating an EAI system 200, in accordancewith an embodiment of the present invention. EAI system 200 comprisesone or more IDE clients 202 and a repository 204. EAI system 200 mayalso comprise an integrated VCS (not shown) that is provided with EAIsystem 200. However, it is presumed that a third party VCS is usedrather than the native VCS; hence, there is a need for a VCS API.

IDE Client and Repository

With an IDE client, such as IDE client 202, a user defines all orportions of an enterprise application. For example, a user may developenterprise applications through all phases of development—generatingsource code, compiling the source code, and debugging the sourcecode—all with an IDE client. Overall, a user may use IDE client 202 todefine functional software components that can be executed to give riseto an enterprise application. When the user is ready to save components,the user causes IDE client 202 to invoke repository 204. Repository 204responds by causing components (which may take the form of definition,configuration, and/or executable files) to be stored in a VCS.Similarly, repository 204 accesses components requested by IDE client202.

Although IDE client 202 “knows” that it is saving and accessingcomponents, IDE client 202 may be unaware that any VCS is involved. Asfar as IDE client 202 knows, IDE client 202 is simply saving andaccessing components. On the other hand, repository 204 knows that it isinteracting with a VCS; however, repository 204 is not required to knowwhich particular VCS it is interacting with. The API implementationtakes care of the specifics of the VCS. In software terms, the thirdparty VCS is “transparent” to IDE client 202 and repository 204. Inother words, in the views of IDE client 202 and repository 204, it is asif the native VCS provided with EAI system 200 were used instead of athird party VCS.

With the information from IDE client 202, repository 204 invokes a VCSAPI 206. By doing so, repository 204 causes components to be stored in,or accessed from, a VCS, such as VCS 210. In one embodiment, the VCS isnot native to EAI system 200 but is provided by a third party. VCS API206 provides repository 204 with a standard interface that it can use tointeract with any third party VCS. The API implementation will translatethe API calls into proper calls for invoking the functionalities of thespecific third party VCS.

Components

Components are analogous to source files with a traditional IDE.Components are not required to be stored locally on a user's system(like files) but rather may be stored through the repository.

Components may be any of various types of files, such as files from aJava collaboration and object type definitions or OTDs (which representdifferent kinds of messages that are used in executing EAIapplications). Components may include definition files, configurationfiles, executable files, and all metadata about a particular projectthat is built. Ultimately, components may be stored in a VCS as a file.In one embodiment, a component is an XML file that describes an object,which indicates that the repository may model an object database.

VCS API

VCS API 206 provides methods that can be called by repository 204 toaccess and store components. Some methods may include:

checkIn: Allows the user to check in objects to VC

checkOutForRead: Allows the user to check out objects for read only

checkOutForWrite: Allows the user to check out objects for write withlock

getHistory: Allows the user to get history of an object

label: Allows the user to label objects

unlock: Allows the user to unlock the objects locked by checkOutForWriteoperation

createBranch: Allows the user to create a new branch

getAllBranchNames: Gets all the branches in the VC repository

tag: Allows the user to create a new tag

API Implementations

API implementations, such as API implementation 208, implement VCS API206. There is one API implementation for each VCS. The APIimplementation translates calls to the methods of the API into propercalls for invoking the functionalities of the specific VCS. In normaloperation, because only one VCS is used at a time, only one APIimplementation is required. In order to use another VCS, another APIimplementation is implemented. Multiple API implementations (i.e., 208and 209) are shown to illustrate that any VCS may be used, so long as aproper API implementation is provided. Each VCS may provide a differentinterface for interacting with other components. Thus, an APIimplementation includes logic to properly interact with a VCS (e.g.,call the right methods of the VCS).

For example, suppose a VCS provides several methods that can be invoked,such as “check-in” and “check-out”. Suppose further that these methodsneed to be invoked in a certain way using a certain call or messageformat; suppose further that the API has the methods “save” and“retrieve”. When the repository invokes the “save” method, the APIimplementation translates that into a “check-in” request with the properformat. Similarly, when the repository invokes the “retrieve” method,the API implementation translates that into a “check-out” request withthe proper format.

Data Storage

FIG. 2 illustrates that a single data storage container is used for eachVCS (i.e., data storage 212 for VCS 210 and data storage 222 for VCS220). However, a single VCS may use multiple data storage containers forstoring components. Alternatively, multiple VCS may share a single datastorage container.

Sample Operation

The following is an example of how components may be stored and accessedin an EAI system, such as EAI system 200. Using IDE client 202, a userlogs into EAI system 200 and develops a new component for an enterpriseapplication. Using IDE client 202, the user saves the new component.Repository 204 receives the save request and invokes VCS API 206 (e.g.,invokes the “save” method of API 206). In response to the invocation ofthe API 206, the API implementation 208 translates the invocation into aproper call to VCS 210 having the format expected by VCS 210. The propercall may be, for example, “check-in”. The API implementation 208 thensends the call to VCS 210. VCS 210 subsequently checks the component into data storage 212.

Thus, by saving the component, the IDE client is causing the componentto be checked in to a VCS. The IDE client does not even have to be awarethat the component is being checked in to the VCS. With this setup, auser does not have to save a file locally and then affirmatively checkthe component in. The check in process is performed automatically andtransparently to the user, which is a significant improvement over thecurrent methodology.

In one embodiment, repository 204 implements a “workspace” for eachuser. A user may save work (e.g., modified components) to his/herrespective workspace without performing a check-in. Thus, the user maylater choose to check-in a modified component, which then causes VCS API206 to be used and the modified component to be checked into VCS 210.Therefore, in this embodiment, a save operation by a user does notautomatically check-in the component to the appropriate VCS. However,because a user's workspace is still within the repository, differentclient machines may access saved work. Also, saved work is not lost ifthe user fails to check in a modified component as is the case withtraditional IDEs.

In a subsequent session, the user logs into EAI system 200 and desiresto modify the newly created component. Using IDE client 202, the userrequests the component from repository 204. In response to the requestfrom IDE client 202, repository 204 invokes VCS API 206, for example, bycalling the “retrieve” method. API implementation 208 translates the“retrieve” method into a proper call and format, such as a “check-out”call. VCS 210 then checks out the component from data storage 212 andprovides the component to repository 204, which provides the componentto IDE client 202.

EAI system 200 may comprise multiple version control systems (asillustrated), such as VCS 210 and VCS 220. Accordingly, the EAI systemmay comprise multiple API implementations 208 and 209, one for each VCS.In such a system, the user (or another user) may use IDE client 202 tosave components to, and retrieve components from, repository 204. Inresponse to requests to save components, repository 204 invokes methodsof VCS API 206. In response to the invocations of the API 206, one ofthe API implementations (e.g., the API implementation 209) translatesthe invocations into proper calls to VCS 220 having the format expectedby VCS 220. The API implementation 209 then sends the calls to VCS 220to, for example, check components in and out of data storage 222.

In one embodiment, VCS 220, like VCS 210, is not an integrated VCSprovided with repository 204 and/or IDE client 202 but rather is a VCSprovided by a third party.

One benefit of the above approach is that, rather than storing fileslocally, files are stored through a repository, which is a common placethat multiple IDE clients may connect to in order to ensure that allmodified files are checked into a VCS. Otherwise, when working withlocal files, there is a significant risk that one or more users willforget to perform a check-in of modified components, thus losingimportant changes and wasting valuable time.

Hardware Overview

FIG. 3 shows one possible embodiment of a platform for executing theinstructions. Computer system 300 includes a bus 302 for facilitatinginformation exchange, and one or more processors 304 coupled with bus302 for processing information. Computer system 300 also includes a mainmemory 306, such as a random access memory (RAM) or other dynamicstorage device, coupled to bus 302 for storing information andinstructions to be executed by processor 304. Main memory 306 also maybe used for storing temporary variables or other intermediateinformation during execution of instructions by processor 304. Computersystem 300 may further include a read only memory (ROM) 308 or otherstatic storage device coupled to bus 302 for storing static informationand instructions for processor 304. A storage device 310, such as amagnetic disk or optical disk, is provided and coupled to bus 302 forstoring information and instructions.

Computer system 300 may be coupled via bus 302 to a display 312 fordisplaying information to a computer user. An input device 315,including alphanumeric and other keys, is coupled to bus 302 forcommunicating information and command selections to processor 304.Another type of user input device is cursor control 316, such as amouse, a trackball, or cursor direction keys for communicating directioninformation and command selections to processor 304 and for controllingcursor movement on display 312. This input device typically has twodegrees of freedom in two axes, a first axis (e.g., x) and a second axis(e.g., y), that allows the device to specify positions in a plane.

In computer system 300, bus 302 may be any mechanism and/or medium thatenables information, signals, data, etc., to be exchanged between thevarious components. For example, bus 302 may be a set of conductors thatcarries electrical signals. Bus 302 may also be a wireless medium (e.g.,air) that carries wireless signals between one or more of thecomponents. Bus 302 may further be a network connection that connectsone or more of the components. Any mechanism and/or medium that enablesinformation, signals, data, etc., to be exchanged between the variouscomponents may be used as bus 302.

Bus 302 may also be a combination of these mechanisms/media. Forexample, processor 304 may communicate with storage device 310wirelessly. In such a case, the bus 302, from the standpoint ofprocessor 304 and storage device 310, would be a wireless medium, suchas air. Further, processor 304 may communicate with ROM 308capacitively. Further, processor 304 may communicate with main memory306 via a network connection. In this case, the bus 302 would be thenetwork connection. Further, processor 304 may communicate with display312 via a set of conductors. In this instance, the bus 302 would be theset of conductors. Thus, depending upon how the various componentscommunicate with each other, bus 302 may take on different forms. Bus302, as shown in FIG. 3, functionally represents all of the mechanismsand/or media that enable information, signals, data, etc., to beexchanged between the various components.

The invention is related to the use of computer system 300 forimplementing the techniques described herein. According to oneembodiment of the invention, those techniques are performed by computersystem 300 in response to processor 304 executing one or more sequencesof one or more instructions contained in main memory 306. Suchinstructions may be read into main memory 306 from anothermachine-readable medium, such as storage device 310. Execution of thesequences of instructions contained in main memory 306 causes processor304 to perform the process steps described herein. In alternativeembodiments, hard-wired circuitry may be used in place of or incombination with software instructions to implement the invention. Thus,embodiments of the invention are not limited to any specific combinationof hardware circuitry and software.

The term “machine-readable medium” as used herein refers to any mediumthat participates in providing data that causes a machine to operationin a specific fashion. In an embodiment implemented using computersystem 300, various machine-readable media are involved, for example, inproviding instructions to processor 304 for execution. Such a medium maytake many forms, including but not limited to, non-volatile media,volatile media, and transmission media. Non-volatile media includes, forexample, optical or magnetic disks, such as storage device 310. Volatilemedia includes dynamic memory, such as main memory 306. Transmissionmedia includes coaxial cables, copper wire and fiber optics, includingthe wires that comprise bus 302. Transmission media can also take theform of acoustic or light waves, such as those generated duringradio-wave and infra-red data communications.

Common forms of machine-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, or any other magneticmedium, a CD-ROM, DVD, or any other optical storage medium, punchcards,papertape, any other physical medium with patterns of holes, a RAM, aPROM, an EPROM, a FLASH-EPROM, any other memory chip or cartridge, acarrier wave as described hereinafter, or any other medium from which acomputer can read.

Various forms of machine-readable media may be involved in carrying oneor more sequences of one or more instructions to processor 304 forexecution. For example, the instructions may initially be carried on amagnetic disk of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 300 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 302. Bus 302 carries the data tomain memory 306, from which processor 304 retrieves and executes theinstructions. The instructions received by main memory 306 mayoptionally be stored on storage device 310 either before or afterexecution by processor 304.

Computer system 300 also includes a communication interface 318 coupledto bus 302. Communication interface 318 provides a two-way datacommunication coupling to a network link 320 that is connected to alocal network 322. For example, communication interface 318 may be anintegrated services digital network (ISDN) card or a modem to provide adata communication connection to a corresponding type of telephone line.As another example, communication interface 318 may be a local areanetwork (LAN) card to provide a data communication connection to acompatible LAN. Wireless links may also be implemented. In any suchimplementation, communication interface 318 sends and receiveselectrical, electromagnetic or optical signals that carry digital datastreams representing various types of information.

Network link 320 typically provides data communication through one ormore networks to other data devices. For example, network link 320 mayprovide a connection through local network 322 to a host computer 324 orto data equipment operated by an Internet Service Provider (ISP) 326.ISP 326 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 328. Local network 322 and Internet 328 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 320and through communication interface 318, which carry the digital data toand from computer system 300, are exemplary forms of carrier wavestransporting the information.

Computer system 300 can send messages and receive data, includingprogram code, through the network(s), network link 320 and communicationinterface 318. In the Internet example, a server 330 might transmit arequested code for an application program through Internet 328, ISP 326,local network 322 and communication interface 318.

The received code may be executed by processor 304 as it is received,and/or stored in storage device 310, or other non-volatile storage forlater execution. In this manner, computer system 300 may obtainapplication code in the form of a carrier wave.

At this point, it should be noted that although the invention has beendescribed with reference to a specific embodiment, it should not beconstrued to be so limited. Various modifications may be made by thoseof ordinary skill in the art with the benefit of this disclosure withoutdeparting from the spirit of the invention. Thus, the invention shouldnot be limited by the specific embodiments used to illustrate it butonly by the scope of the issued claims and the equivalents thereof.

1. A method implemented by a repository, comprising: receiving, from anintegrated development environment (IDE) client, a request to save afirst component developed by a user of the IDE client, wherein the firstcomponent represents a functional component that can be used or executedto derive one or more enterprise application functionalities; and inresponse to the request to save the first component, invoking anapplication programming interface (API) to interact with a first versioncontrol system (VCS) to check the first component into the first VCS,wherein the first VCS is not an integrated VCS provided with therepository and the IDE client, and wherein the API may be invoked tointeract with any VCS.
 2. The method of claim 1, further comprising:receiving, from the IDE client, a request to access a first savedcomponent from the repository, wherein the first saved componentrepresents a functional component that can be used or executed to deriveone or more enterprise application functionalities; and in response tothe request to access the first saved component, invoking the API tointeract with the first VCS to check the first saved component out ofthe first VCS.
 3. The method of claim 2, wherein at least one of thefirst component or the first saved component is a definition file. 4.The method of claim 2, wherein at least one of the first component orthe first saved component is an executable file.
 5. The method of claim1, wherein a first implementation of the API is used to interact withthe first VCS.
 6. The method of claim 5, further comprising: receiving,from the IDE client, a request to save a second component developed by auser of the IDE client, wherein the second component represents afunctional component that can be used or executed to derive one or moreenterprise application functionalities; in response to the request tosave the second component, invoking the API to interact with a secondVCS to check the second component into the second VCS, wherein thesecond VCS is not an integrated VCS provided with the repository and theother IDE client; receiving, from the IDE client, a request to access asaved component from the repository, wherein the saved componentrepresents a functional component that can be used or executed to deriveone or more enterprise application functionalities; and in response tothe request to access the saved component, invoking the API to interactwith the second VCS to check the saved component out of the second VCS;wherein a second implementation of the API is used to interact with thesecond VCS.
 7. A machine-readable medium, comprising one or more sets ofinstructions which, when executed by one or more processors, cause theone or more processors to perform the operations of: receiving, from anintegrated development environment (IDE) client, a request to save afirst component developed by a user of the IDE client, wherein the firstcomponent represents a functional component that can be used or executedto derive one or more enterprise application functionalities; and inresponse to the request to save the first component, invoking anapplication programming interface (API) to interact with a first versioncontrol system (VCS) to check the first component into the first VCS,wherein the first VCS is not an integrated VCS provided with therepository and the IDE client, and wherein the API may be invoked tointeract with any VCS.
 8. The machine-readable medium of claim 7,further comprising: receiving, from the IDE client, a request to accessa first saved component from the repository, wherein the first savedcomponent represents a functional component that can be used or executedto derive one or more enterprise application functionalities; and inresponse to the request to access the first saved component, invokingthe API to interact with the first VCS to check the first savedcomponent out of the first VCS.
 9. The machine-readable medium of claim8, wherein at least one of the first component or the first savedcomponent is a definition file.
 10. The machine-readable medium of claim8, wherein at least one of the first component or the first savedcomponent is an executable file.
 11. The machine-readable medium ofclaim 7, wherein a first implementation of the API is used to interactwith the first VCS.
 12. The machine-readable medium of claim 11, furthercomprising: receiving, from the IDE client, a request to save a secondcomponent developed by a user of the IDE client, wherein the secondcomponent represents a functional component that can be used or executedto derive one or more enterprise application functionalities; inresponse to the request to save the second component, invoking the APIto interact with a second VCS to check the second component into thesecond VCS, wherein the second VCS is not an integrated VCS providedwith the repository and the other IDE client; receiving, from the IDEclient, a request to access a saved component from the repository,wherein the saved component represents a functional component that canbe used or executed to derive one or more enterprise applicationfunctionalities; and in response to the request to access the savedcomponent, invoking the API to interact with the second VCS to check thesaved component out of the second VCS; wherein a second implementationof the API is used to interact with the second VCS.
 13. An enterpriseapplication integration (EAI) system, comprising: an integrateddevelopment environment (IDE) client, the IDE client enabling a user todevelop one or more functional components that can be used or executedto derive one or more enterprise application functionalities; arepository, the repository interacting with the IDE client to save andaccess functional components; an application programming interface (API)that can be invoked by the repository to interact with any versioncontrol system (VCS); and a first API implementation which enables therepository, by way of invoking the API, to interact with a first VCS,wherein the first VCS is an external VCS which is not provided as partof the EAI system.
 14. The system of claim 13, wherein the repositoryreceives, from the IDE client, a request to save a first functionalcomponent developed by a user of the IDE client, and in response, therepository invoking the API, which in turn, uses the first APIimplementation, to interact with the first VCS to check the firstfunctional component into the first VCS.
 15. The system of claim 14,wherein the repository receives, from the IDE client, a request toaccess a first saved functional component, and in response, therepository invoking the API, which in turn, uses the first APIimplementation, to interact with the first VCS to check the first savedfunctional component out of the first VCS.
 16. The system of claim 15,wherein the system further comprises a second API implementation whichenables the repository, by way of invoking the API, to interact with asecond VCS, wherein the second VCS is an external VCS which is notprovided as part of the EAI system, and wherein the second VCS isdifferent from the first VCS.
 17. The system of claim 16, wherein therepository receives, from the IDE client, a request to save a secondfunctional component developed by a user of the IDE client, and inresponse, the repository invoking the API, which in turn, uses thesecond API implementation, to interact with the second VCS to check thesecond functional component into the second VCS.
 18. The system of claim17, wherein the repository receives, from the IDE client, a request toaccess a second saved functional component, and in response, therepository invoking the API, which in turn, uses the second APIimplementation, to interact with the second VCS to check the secondsaved functional component out of the second VCS.
 19. The system ofclaim 13, wherein at least one of the functional components is adefinition file.
 20. The system of claim 13, wherein at least one of thefunctional components is an executable file.